1. Field of the Invention
The invention relates generally to a method for regression-test simulation of logic designs and, more particularly, to a method for evaluating and selecting test cases used in regression-test simulation of logic designs to improve the speed and effectiveness of such a test simulation.
2. Description of the Related Art
One of the most popular methods of designing complex logic circuits such as Very Large Scale Integrated Circuits (VLSIs) is by designing circuits at a higher level of abstraction and then converting the design into a lower level of abstraction. The highest level is used to describe the behavioral aspect of circuits in a programming language called Hardware Description Language (HDL) such as VHDL, or VHSIC (Very High Speed Integrated Circuit) HDL. The second highest level is a gate-level schematic or net-list. Finally, there is a transistor-level schematic or net-list. Design engineers initially design their circuits at the highest level in HDLs such as VHDL, and then obtain designs at lower levels from the highest-level design. They may test the designs at one or more levels of abstraction, in an effort to design the final circuit layout incorporating all behavioral characteristics of the intended circuit in an effective manner.
For designs described at low levels of abstraction, design engineers have access to commercial tools that successfully automate many design steps. For example, some of these tools can synthesize integrated circuit layouts directly from design descriptions written in standard HDLs. The models that are input to these synthesis tools are generally written at a level of abstraction called Register-Transfer Level (RTL). At this level, the input and output signals of the design are represented as bits and bit vectors. Since behavior is defined over these signals for every step of the system clock, RTL descriptions for complex circuits can easily fill thousands of pages. Because they are highly complex, it is normally quite difficult to determine from RTL models whether the system represented meets the system requirements. Therefore, the usual approach is to build requirements models at a much more abstract level than that of RTL. This abstract specification level is usually termed a “behavioral level.” The simplicity of behavioral models makes them relatively easy to analyze and, if they are written in an executable language, faster to test through simulation. Behavioral models represent excellent specifications for RTL models in a top-down design paradigm.
Generating an implementing RTL model from a behavioral specification model can be difficult because of the vast differences in the levels of abstraction. For example, in contrast to the bits and bit vectors of RTL models, behavioral models often employ more complex data types such as arrays, records, and enumerated types. Furthermore, the time steps used at the behavioral level might represent long sequences of RTL time steps.
Today, a common simulation practice is to automate much of the detailed interaction with the implementation model within a second simulation model. This second simulation model acts as the environment for the implementation. Such environment models, often called “test benches,” can vary quite drastically in their ability to reduce the designer workload at simulation time. At one extreme, the test bench might simply read input test vectors from a file, apply the vectors to the implementation model, and then write the implementation outputs to a second file. Such a test bench would be relatively easy to construct, but would offer little automation since the designer would still be required to generate the input vectors stored in the input file and to certify the results stored into the output file.
One of the major problems facing integrated circuit (IC) design engineers is the verification of their lower-level designs before the designs are fabricated in a hardware form. In particular, engineers face constant pressure to deliver larger and more complex designs in shorter design cycle times and still ensure that the devices flawlessly perform the desired functions. As hardware designs become more and more complex, logic simulation test cases and environments also become more and more complex. Hand-written test cases become time-prohibitive, whereas automatic test generation may easily lead to test cases running thousands of cycles with no accountability. If a circuit is not tested for all expected behavior, some defects may be undetected during logic simulation. In addition, because of unexpected situations, there may be a combination of events that a test bench does not check. Test cases, whether generated automatically or manually, are not generally optimized to cover a test bench 100%. Some test cases may be redundant, overlapping with other test cases in test coverage.
Therefore, there is a need for a method of selecting and maintaining effective test cases in a simulation environment (i.e., a test bench) for hardware designs.